A unified communications (UC) system generally refers to a system that provides users with an integration of communications services. Users typically connect to the UC system through a single client to access the integrated communications services. The integrated communications services may include real-time services, such as instant messaging (IM), presence notifications, telephony, and video conferencing, as well as non-real-time services, such as email, SMS, fax, and voicemail.
Organizations, such as corporations, businesses, educational institutions, and government entities, often employ UC systems to enable internal communication among its members in a uniform and generally cost-efficient manner. In addition, organizations may employ UC systems for communicating with trusted external entities.
Currently, a number of third-party developers offer various UC applications for implementing UC systems. The various applications include Microsoft Office Communications Server (OCS), IBM Sametime (ST), Google Apps, and Cisco Jabber.
Often, a UC system needs to communicate with a different UC system. For example, a corporation or business that employs a particular UC system may desire to communicate externally with vendors or other persons who employ a different UC system. Or in the case of internal communication, when an organization that employs a particular UC system “A” merges with another organization that employs a UC system “B,” the ability for users on system “A” to communicate with users on system “B” is often desirable.
Because there is no industry standard regarding UC systems, communications between different UC systems give rise to issues of incompatibility. These issues often make communication between the UC systems difficult or impossible to implement. One aspect of UC system incompatibility is whether or not systems attempting to communicate support proxies. If a UC system based on standards and protocols that do not accommodate proxies attempts to establish communications with a proxy-based system, the attempt will fail: the respective protocols to establish a connection will, in effect, talk past each other. For example, Cisco Jabber is not compatible with Microsoft OCS. The incompatibility is because Jabber is based on the Extensible Messaging and Presence Protocol (“XMPP”), which does not accommodate proxies, while Microsoft OCS is based on the Session Initiation Protocol (“SIP”), which does accommodate proxies.
FIG. 1 is a diagram that illustrates the concept of a proxy. In FIG. 1, Charles at computer 110 communicates with Jonas at computer 120 through proxy computer 130. Charles and Jonas do not communicate directly: computer 110 does not send message data to computer 120. Rather, proxy computer 130 is in communication with both computers 110 and 120, and acts as an intermediary.
FIG. 2 is a diagram of a proxy in a networked environment that illustrates a conventional advantage of proxies. In FIG. 2, user computer 210 and proxy computer 220 are elements of internal network 230. The internal network is in communication with Internet 240, including a domain 250 named example.com. A domain is a sub-network. As described in regard to FIG. 1, user computer 210 communicates outside of the internal network through the proxy computer: for example, there is no direct communication from the user computer to example.com. One advantage of using a proxy is that the proxy computer is a shield against external computers. In more complicated examples of networks (not shown), another advantage is that proxy computers enable complex routing schemes between various computers.
FIG. 3 is a diagram of a network topology that illustrates the proxy-based protocol to proxy-free protocol communications problem. FIG. 3 shows domain 310, domain 320, domain 330, and domain 340 connected by network 300. Each domain includes a UC device; here, a server with multiple users. In the domain 310, UC server 311 has user_1 312, user_2 313 and user_3 314. Domain 310 also includes proxy computer 315, and runs Microsoft Office Communication Server (OCS). In the domain 320, website 321 has user_1 322, user_2 323 and user_3 324. Domain 320 includes one proxy computer 325, and runs Microsoft OCS. In domain 330, UC server 331 has user_1 332, user_2 333 and user_3 334 running Cisco Jabber. Domain 330 is proxy-free: it does not include a proxy computer. In domain 340, UC server 341 has user_1 342, user_2 343, user_3 344 running Cisco Jabber. Domain 340 is proxy free. In FIG. 3, users 312-314 can communicate with users 332-334 over the network, however, communication with users on domains 320 and 340 is problematic, if not impossible.
One conventional solution to the compatibility problem is a system-wide shift to one UC system or another. In the foregoing example of merging business entities using UC system “A” and “B,” the merged organization can abandon one or the other UC system, and re-provision uniformly. In FIG. 3, users in domains 330 and 340 could abandon Cisco Jabber and adopt Microsoft OCS. But this can be expensive and in some cases impractical. Other conventional solutions are multi-protocol clients, or multi-protocol servers, or a gateway that receives communications entering a domain and translates syntax and semantics of an incompatible protocol into the syntax and semantics of a compatible protocol. But these solutions are lacking because they typically result in reduced usability of the UC system, or are not scalable, or rely on expensive added infrastructure. What is needed instead is a less expensive and scalable solution that allows for seamless federation between proxy-based and proxy-less systems.